I think this may be a semantics problem, but in the book, the approach that is described as optimistic concurrency is a bit different than real optimistic concurrency. It still throws an error because of the isolation level "repeatable read" and achieves the same thing though.

As far as I understand, optimistic concurrency should try to make an update by checking the previous version, and if the version number is different than what the original version number is, it fails. Not because two processes are touching the same database row, bout because of a version difference.

I think SQL Alchemy automatically provides this field for this purpose version_id_col=products.c.version_number. Here is an integration test with two threads, both trying to update the same product field with the same sku. Only one succeeds, the other fails as stale data.

Personally, I don't know which approach is better.

I wanted to get your opinion on whether you have any preference between these two approaches @hjwp

As I said, I think they are both really similar and can act as optimistic concurrency, but usually, when I see the description for optimistic concurrency, it means that

A tries to update the database row, increase the version
B tries to update the database where version_number ={old_version} -> returns 0 because the version is changed, so it gets rejected.

The approach in the pr simulates that a bit closer.

Thank you for all the examples in the book!